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Use of ISO CLNP in TUBA Environments 
Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. This memo does not specify an Internet standard of any 
kind. Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Abstract 


This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode 
Network Layer Protocol (CLNP, [1]) for use in conjunction with RFC 
1347, TCP/UDP over Bigger Addresses (TUBA, [2]). It describes the 
use of CLNP to provide the lower-level service expected by 
Transmission Control Protocol (TCP, [3]) and User Datagram Protocol 
(UDP, [4]). CLNP provides essentially the same datagram service as 
Internet Protocol (IP, [5]), but offers a means of conveying bigger 
network addresses (with additional structure, to aid routing). 


While the protocols offer nearly the same services, IP and CLNP are 
not identical. This document describes a means of preserving the 
semantics of IP information that is absent from CLNP while preserving 
consistency between the use of CLNP in Internet and OSI environments. 
This maximizes the use of already-deployed CLNP implementations. 
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Conventions 


l« 


The following language conventions are used in the items of 
Specification in this document: 


* MUST, SHALL, or MANDATORY -- the item is an absolute 
requirement of the specification. 


* SHOULD or RECOMMENDED -- the item should generally be 
followed for all but exceptional circumstances. 


* MAY or OPTIONAL -- the item is truly optional and may be 
followed or ignored according to the needs of the 
implementor. 

Terminology 


To the extent possible, this document is written in the language of 
the Internet. For example, packet is used rather than "protocol data 
unit", and "fragment" is used rather than "segment". There are some 
terms that carry over from OSI; these are, for the most part, used so 
that cross-reference between this document and RFC 994 [6] or ISO/IEC 
8473 is not entirely painful. OSI acronyms are for the most part 
avoided. 


Introduction 


The goal of this specification is to allow compatible and 
interoperable implementations to encapsulate TCP and UDP packets in 
CLNP data units. In a sense, it is more of a "hosts requirements" 
document for the network layer of TUBA implementations than a 
protocol specification. It is assumed that readers are familiar with 
STD 5, RFC 791, STD 5, RFC 792 [7], STD 3, RFC 1122 [8], and, to a 
lesser extent, RFC 994 and ISO/IEC 8473. This document is compatible 
with (although more restrictive than) ISO/IEC 8473; specifically, the 
order, semantics, and processing of CLNP header fields is consistent 
between this and ISO/IEC 8473. 


[Note: RFC 994 contains the Draft International Standard version of 
ISO CLNP, in ASCII text. This is not the final version of the ISO/IEC 
protocol specification; however, it should provide sufficient 
background for the purpose of understanding the relationship of CLNP 
to IP, and the means whereby IP information is to be encoded in CLNP 
header fields. Postscript versions of ISO CLNP and associated routing 
protocols are available via anonymous FTP from merit.edu, and may be 
found in the directory /pub/ISO/IEC. 
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3. Overview of CLNP 


ISO CLNP is a datagram network protocol. It provides fundamentally 
the same underlying service to a transport layer as IP. CLNP provides 
essentially the same maximum datagram size, and for those 
circumstances where datagrams may need to traverse a network whose 
maximum packet size is smaller than the size of the datagram, CLNP 
provides mechanisms for fragmentation (data unit identification, 
fragment/total length and offset). Like IP, a checksum computed on 
the CLNP header provides a verification that the information used in 
processing the CLNP datagram has been transmitted correctly, anda 
lifetime control mechanism ("Time to Live") imposes a limit on the 
amount of time a datagram is allowed to remain in the internet 
system. As is the case in IP, a set of options provides control 
functions needed or useful in some situations but unnecessary for the 
most common communications. 


Note that the encoding of options differs between the two protocols, 
as do the means of higher level protocol identification. Note also 
that CLNP and IP differ in the way header and fragment lengths are 
represented, and that the granularity of lifetime control (time-to- 
live) is finer in CLNP. 


Some of these differences are not considered "issues", as CLNP 
provides flexibility in the way that certain options may be specified 
and encoded (this will facilitate the use and encoding of certain IP 
options without change in syntax); others, e.g., higher level 
protocol identification and timestamp, must be accommodated in a 
transparent manner in this profile for correct operation of TCP and 
UDP, and continued interoperability with OSI implementations. Section 
4 describes how header fields of CLNP must be populated to satisfy 
the needs of TCP and UDP. 


Errors detected during the processing of a CLNP datagram MAY be 
reported using CLNP Error Reports. Implementations of CLNP for TUBA 
environments MUST be capable of processing Error Reports (this is 
consistent with the 1992 edition (2) of the ISO/IEC 8473 standard). 
Control messages (e.g., echo request/reply and redirect) are 
similarly handled in CLNP, i.e., identified as separate network layer 
packet types. The relationship between CLNP Error and Control 
messages and Internet Control Message Protocol (ICMP, [7]), and 
issues relating to the handling of these messages is described in 
Section 5. 
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Table 1 provides a high-level comparison of CLNP to IP: 


Function 

Header Length 
Version Identifier 
Lifetime (TTL) 
Flags 


Packet Type 

Fragment Length 
Header Checksum 

Total Length 
Addressing 

Data Unit Identifier 
Fragment offset 
Higher Layer Protocol 
Options 


Table 


indicated in octets 

1 octet 

500 msec units 
Fragmentation allowed, 
More Fragments 
Suppress Error Reports 
5 bits 

16 bits, in octets 
16-bit (Fletcher) 

16 bits, in octets 
Variable length 

16 bits 
16 bits, 
Selector 
Security 
Priority 
Complete Source Route 
Quality of Service 
Partial Source Route 
Record Route 

Padding 

<defined herein> 


in octets 
in address 


in 32-bit words 

4 bits 

1 sec units 

Don’t Fragment, 
More Fragments, 
<not defined> 

<not defined> 

16 bits, in octets 
16-bit 

<not defined> 
32-bit fixed 

16 bits 
13 bits, 
Protocol 
Security 
TOS Precedence bits 
Strict Source Route 
Type of Service 
Loose Source Route 
Record Route 
Padding 

Timestamp 


8-octet units 


Comparison of IP to CLNP 


The composition and processing of a TCP pseudo-header when CLNP is 
used to provide the lower-level service expected by TCP and UDP is 
described in Section 6. 


[Note: 
Presently, 
ISO/IEC/JTC1/SC6, 


This experimental RFC does not discuss multicasting. 
there are proposals for multicast extensions for CLNP in 
and a parallel effort within TUBA. A future 


revision to this RFC will incorporate any extensions to CLNP that may 
be introduced as a result of the adoption of one of these 


alternatives. ] 
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4. Proposed Internet Header using CLNP 


A summary of the contents of the CLNP header, as it is proposed for 
use in TUBA environments, is illustrated in Figure 4-1: 


0 1 2 3 
Oud 3 dD 6: B89 0 1.-2;:3 4. DO E 58:90 D 2-3. db: 677-8: 9: 0. T 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


人 Data Link Header........ | NLP ID 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
|Header Length | Version | Lifetime (TTL) |Flags| Type | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Fragment Length | Checksum 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Dest Addr Len | Destination Address... 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| ... Destination Address... 

Fatt ata ta tata e tantra ta tata tata tat e 4 ——4—4—4-4-4-4-4-4-4 
... Destination Address... 

—t-—t-t-—t-—t—t—tL-—L———4—4—4-—4-.-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-— 
... Destination Address... 

—t-t-t-t-—t—t—t-—————4-—4-—4-.-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-4— 
... Destination Address... 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

PROTO field Src Addr Len Source Address... 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Source Address... | 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Source Address... 

—t-*-t-—t-—t—t—tL-—L———4—4-—4-—4-4-t-t-t-t-t-t-t-t-t-t-t-t-t-t-t-4— 
... Source Address... 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Source Address... 

T—R—4—4—4-4-t-t-t-----*-t-t-t-t-—t-—tL-L-4— 4 —4—4-4-—4-4-4-4-4-4 


一 + 一 + 一 + 一 + 一 + 一 + 一 + 一 


|Source Address Reserved | Data Unit Identifier 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Fragment Offset | Total Length of packet 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Options (see Table 1) 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Data | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Note that each tick mark represents one bit position. 


Figure 4-1. CLNP for TUBA 
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Note 1: For illustrative purposes, Figure 4-1 shows Destination 
and Source Addresses having a length of 19 octets, 
including the PROTO/reserved field. In general, addresses 
can be variable length, up to a maximum of 20 octets, 
including the PROTO/reserved field. 


Note 2: Due to differences in link layer protocols, it is not 
possible to ensure that the packet starts on an even 
alignment. Note, however, that many link level protocols 
over which CLNP is operated use a odd length link 
(e.g., IEEE 802.2). (In Figure 4-1, the rest of the CLNP 
packet is even-aligned.) 


The encoding of CLNP fields for use in TUBA environments is as 
follows. 


4.1 Network Layer Protocol Identification (NLP ID) 


This one-octet field identifies this as the ISO/IEC 8473 protocol; it 
MUST set to binary 1000 0001. 


4.2 Header Length Indication (Header Length) 


Header Length is the length of the CLNP header in octets, and thus 
points to the beginning of the data. The value 255 is reserved. The 
header length is the same for all fragments of the same (original) 
CLNP packet. 


4.3 Version 


This one-octet field identifies the version of the protocol; it MUST 
be set to a binary value 0000 0001. 


4.4 Lifetime (TTL) 


Like the TTL field of IP, this field indicates the maximum time the 
datagram is allowed to remain in the internet system. If this field 
contains the value zero, then the datagram MUST be destroyed; a host, 
however, MUST NOT send a datagram with a lifetime value of zero. 

This field is modified in internet header processing. The time is 
measured in units of 500 milliseconds, but since every module that 
processes a datagram MUST decrease the TTL by at least one even if it 
process the datagram in less than 500 millisecond, the TTL must be 
thought of only as an upper bound on the time a datagram may exist. 
The intention is to cause undeliverable datagrams to be discarded, 
and to bound the maximum CLNP datagram lifetime. [Like IP, the 
colloquial usage of TTL in CLNP is as a coarse hop-count.] 
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4. 


5 


Unless otherwise directed, a host SHOULD use a value of 255 as the 
initial lifetime value. 


Flags 


Three flags are defined. These occupy bits 0, 1, and 2 of the 
Flags/Type octet: 


The Fragmentation Permitted (FP) flag, when set to a value of one 
(1), is semantically equivalent to the "may fragment" value of the 
Don't Fragment field of IP; similarly, when set to zero (0), the 
Fragmentation Permitted flag is semantically equivalent to the "Don't 
Fragment" value of the Don't Fragment Flag of IP. 


[Note: If the Fragmentation Permitted field is set to the value 0, 
then the Data Unit Identifier, Fragment Offset, and Total Length 
fields are not present. This denotes a single fragment datagram. In 
such datagrams, the Fragment Length field contains the total length 
of the datagram.] 


The More Fragments flag of CLNP is semantically and syntactically the 
same as the More Fragments flag of IP; a value of one (1) indicates 
that more segments/fragments are forthcoming; a value of zero (0) 
indicates that the last octet of the original packet is present in 
this segment. 


The Error Report (ER) flag is used to suppress the generation of an 
error message by a host/router that detects an error during the 
processing of a CLNP datagram; a value of one (1) indicates that the 
host that originated this datagram thinks error reports are useful, 
and would dearly love to receive one if a host/router finds it 
necessary to discard its datagram(s). 
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4.6 Type field 


The type field distinguishes data CLNP packets from Error Reports 
from Echo packets. The following values of the type field apply: 


0 1 2 3 4 5 6 7 
十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 


| flags | 1 | 1 | 1 | 0 | 0 | => Encoding of Type = data packet 
十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 

| flags | o|o]o|o |1| => Encoding of Type = error report 
十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 

| flags | 1 | 1 | 1 | 1 | 0 | => Encoding of Type = echo request 
十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 

| flags | 1 | 1 | 1 | 1 | 1 | => Encoding of Type = echo reply 


+—---+---+---4+---+---+---4+---4+---+ 

Error Report packets are described in Section 5. 

Echo packets and their use are described in RFC 1139 [9]. 
4.7 Fragment Length 


Like the Total Length of the IP header, the Fragment length field 
contains the length in octets of the fragment (i.e., this datagram) 
including both header and data. 


[Note: CLNP also may also have a Total Length field, that contains 
the length of the original datagram; i.e., the sum of the length of 
the CLNP header plus the length of the data submitted by the higher 
level protocol, e.g., TCP or UDP. See Section 4.12.] 


4.8 Checksum 


A checksum is computed on the header only. It MUST be verified at 
each host/router that processes the packet; if header fields are 
changed during processing (e.g., the Lifetime), the checksum is 
modified. If the checksum is not used, this field MUST be coded with 
a value of zero (0). See Appendix A for algorithms used in the 
computation and adjustment of the checksum. Readers are encouraged to 
see [10] for a description of an efficient implementation of the 
checksum algorithm. 


4.9 Addressing 


CLNP uses OSI network service access point addresses (NSAPAs); NSAPAs 
serve the same identification and location functions as an IP 
address, plus the protocol selector value encoded in the IPv4 
datagram header, and with additional hierarchy. General purpose 
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CLNP implementations MUST handle NSAP addresses of variable length up 
to 20 octets, as defined in ISO/IEC 8348 [11]. TUBA implementations, 
especially routers, MUST accommodate these as well. Thus, for 
compatibility and interoperability with OSI use of CLNP, the initial 
octet of the Destination Address is assumed to be an Authority and 
Format Indicator, as defined in ISO/IEC 8348. NSAP addresses may be 
between 8 and 20 octets long (inclusive). 


TUBA implementations MUST support both ANSI and GOSIP style 
addresses; these are described in RFC 1237 [12], and illustrated in 
Figure 4-2. RFC 1237 describes the ANSI/GOSIP initial domain parts 
as well as the format and composition of the domain specific part. It 
is further recommended that TUBA implementations support the 
assignment of system identifiers for TUBA/CLNP hosts defined in [13] 
for the purposes of host address autoconfiguration as described in 
[14]. Additional considerations specific to the interpretation and 
encoding of the selector part are described in sections 4.9.2 and 


4.9.4. 
4+------------- + 
| <-- IDP --> | 
十 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 
|AFI | IDI | «-- DSP --> 
十 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 十 一 一 一 十 一 一 一 一 一 十 一 一 一 一 十 一 一 一 一 一 十 一 一 一 十 一 一 一 一 十 
| 47 | 0005 |DFI |AA |Rsvd | RD |Area |ID |Sel | 
十 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 十 一 一 一 十 一 一 一 一 一 十 一 一 一 一 十 一 一 一 一 一 十 一 一 一 十 一 一 一 一 十 
octets | 1 | 2 ode, dome ER «que uUum Ee 
十 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 十 一 一 一 十 一 一 一 一 一 十 一 一 一 一 十 一 一 一 一 一 十 一 一 一 十 一 一 一 一 十 
Figure 4-2 (a): GOSIP Version 2 NSAP structure. 
4R------------- * 
|<-- IDP --» | 
十 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 
|AFI | IDI | «-- DSP --> 
十 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 十 一 一 一 十 一 一 一 一 一 十 一 一 一 一 十 一 一 一 一 一 十 一 一 一 十 一 一 一 一 十 
| 39 | 840 |DFI |oRG|Rsvd | RD |Area |ID |Sel | 
十 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 十 一 一 一 十 一 一 一 一 一 十 一 一 一 一 十 一 一 一 一 一 十 一 一 一 十 一 一 一 一 十 
octets | 1 | 2 IARE DCN E EE EP ES 
十 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 十 一 一 一 十 一 一 一 一 一 十 一 一 一 一 十 一 一 一 一 一 十 一 一 一 十 一 一 一 一 十 


Figure 4-2 (b): ANSI NSAP address format for DCC=840 


Piscitello [Page 9] 


RFC 1561 CLNP in TUBA Environments December 1993 


4 


4. 


4. 


4. 


Definitions: 
IDP Initial Domain Part 
AFI Authority and Format Identifier 
IDI Initial Domain Identifier 
DSP Domain Specific Part 
DFI DSP Format Identifier 
AA Administration Authority 
ORG Organization Name (numeric form) 
Rsvd Reserved 


RD Routing Domain Identifier 
Area Area Identifier 
ID System Identifier 


Sel NSAP Selector 


.9.1 Destination Address Length Indicator 


This field indicates the length, in octets, of the Destination 
Address. 


9.2 Destination Address 


This field contains an OSI NSAP address, as described in Section 4.9. 
It MUST always contain the address of the final destination. (This is 
true even for packets containing a source route option, see Section 
4.13.4). 


The final octet of the destination address MUST always contain the 
value of the PROTO field, as defined in IP. The 8-bit PROTO field 
indicates the next level protocol used in the data portion of the 
CLNP datagram. The values for various protocols are specified in 
"Assigned Numbers" [15]. For the PROTO field, the value of zero (0) 
is reserved. 


TUBA implementations that support TCP/UDP as well as OSI MUST use the 
protocol value (1Dh, Internet decimal 29) reserved for ISO transport 
protocol class 4. 
9.3 Source Address Length Indicator 

This field indicates the length, in octets, of the Source Address. 
9.4 Source Address 

This field contains an OSI NSAP address, as described in Section 4.9. 
The final octet of the source address is reserved. It MAY be set to 


the protocol field value on transmission, and shall be ignored on 
reception (the value of zero MUST not be used). 
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4.10 Data Unit Identifier 


Like the Identification field of IP, this 16-bit field is used to 
distinguish segments of the same (original) packet for the purposes 
of reassembly. This field is present when the fragmentation permitted 
flag is set to one. 


4.11 Fragment Offset 
Like the Fragment Offset of IP, this 16-bit is used to identify the 


relative octet position of the data in this fragment with respect to 
the start of the data submitted to CLNP; i.e., it indicates where in 


the original datagram this fragment belongs. The offset is measured 
in octets; the value of this field shall always be a multiple of 
eight (8). This field is present when the fragmentation permitted 


flag is set to one. 
4.12 Total Length 


The total length of the CLNP packet in octets is determined by the 
originator and placed in the Total Length field of the header. The 
Total Length field specifies the entire length of the original 
datagram, including both the header and data. This field MUST NOT be 
changed in any fragment of the original packet for the duration of 
the packet lifetime. This field is present when the fragmentation 
permitted flag is set to one. 


4.13 Options 


All CLNP options are "triplets" of the form <parameter code>, 
<parameter length>, and <parameter value>. Both the parameter code 
and length fields are always one octet long; the length parameter 
value, in octets, is indicated in the parameter length field. The 
following options are defined for CLNP for TUBA. 


4.13.1 Security 


The value of the parameter code field is binary 1100 0101. The length 
field MUST be set to the length of a Basic (and Extended) Security IP 
option(s) as identified in RFC 1108 [16], plus 1. Octet 1 of the 
security parameter value field -- the CLNP Security Format Code -- is 
set to a binary value 0100 0000, indicating that the remaining octets 
of the security field contain either the Basic or Basic and Extended 
Security options as identified in RFC 1108. This encoding points to 
the administration of the source address (e.g., ISOC) as the 
administration of the security option; it is thus distinguished from 
the globally unique format whose definition is reserved for OSI use. 
Implementations wishing to use a security option MUST examine the 
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PROTO field in the source address; if the value of PROTO indicates 
the CLNP client is TCP or UDP, the security option described in RFC 
1108 is used. 


[Note: If IP options change, TUBA implementations MUST follow the new 
recommendations. This RFC, or revisions thereof, must document the 
new recommendations to assure compatibility. ] 


The formats of the Security option, encoded as a CLNP option, is as 
follows. The CLNP option will be used to convey the Basic and 
Extended Security options as sub-options; i.e., the exact encoding of 
the Basic/Extended Security IP Option is carried in a single CLNP 
Security Option, with the length of the CLNP Security option 
reflecting the sum of the lengths of the Basic and Extended Security 


IP Option. 
+-------- +-------- +-------- +-------- +-------- +---//----+- 
|11000100 | XXXXXXXX |01000000 |10000010 | yyyyyyYY | 
十 一 一 一 一 一 一 一 一 二 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 +-------- +---//----+---- 
CLNP CLNP CLNP BASIC BASIC BASIC 
OPTION OPTION FORMAT SECURITY OPTION OPTION 
TYPE LENGTH CODE TYPE LENGTH VALUE 
(197) (130) 
i A 于 三才 三 三 二 二 二 二 三 二 二 二 yn + 
| 10000101 | OOOLLLLL | 
全 三 三 = 全 本 一 一 二 三 三 一 三 一 二 二 一 一 十 二 二 二 二 一 二 一 三 一 一 二 一直 二 三 一 二 办 /一 一 一 = 一 一 一 汕 
EXTENDED EXTENDED EXTENDED OPTION 
OPTION OPTION VALUE 
TYPE (133) LENGTH 


The syntax, semantics and processing of the Basic and Extended IP 
Security Options are defined in RFC 1108. 


4.13.2 Type of Service 


[Note: Early drafts recommended the use of IP Type of Service as 
specified in RFC 1349. There now appears to be a broad consensus that 
this encoding is insufficient, and there is renewed interest in 
exploring the utility of the "congestion experienced" flag available 
in the CLNP QOS Maintenance option. This RFC thus recommends the use 
of the QOS Maintenance option native to CLNP.] 


The Quality of Service Maintenance option allows the originator of a 
CLNP datagram to convey information about the quality of service 
requested by the originating upper layer process. Routers MAY use 
this information as an aid in selecting a route when more than one 
route satisfying other routing criteria is available and the 
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available routes are know to differ with respect to the following 
qualities of service: ability to preserve sequence, transit delay, 
cost, residual error probability. Through this option, a router may 
also indicate that it is experiencing congestion. 


The encoding of this option is as follows: 


十 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 +---------- + 
| 1100 0011 | 0000 0001 | 110ABCDE 
prish ceho dci EE t 
CLNP QOS OPTION QOS FLAGS 
TYPE (195) LENGTH 


The value of the parameter code field MUST be set to a value of 
binary 1100 0011 (the CLNP Quality of Service Option Code point). 
The length field MUST be set to one (1). 


Bits 8-6 MUST be set as indicated in the figure. The flags "ABCDE" 
are interpreted as follows: 


A=1 choose path that maintains sequence over 
one that minimizes transit delay 
A-0 choose path that minimizes transit delay over 
one that maintains sequence 
B-1 congestion experienced 
B-0 no congestion to report 
C-1 choose path that minimizes transit delay over 
over low cost 
C=0 choose low cost over path that 
minimizes transit delay 
D=1 choose pathe with low residual error probability over 
one that minimizes transit delay 
D=0 choose path that minimizes transit delay over 
one with low residual error probability 
E=1 choose path with low residual error probability over 
low cost 
E=0 choose path with low cost over one with low 
residual error probability 


4.13.3 Padding 


The padding field is used to lengthen the packet header to a 
convenient size. The parameter code field MUST be set to a value of 
binary 1100 1100. The value of the parameter length field is 
variable. The parameter value MAY contain any value; the contents of 
padding fields MUST be ignored by the receiver. 
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4+---------- 4+---------- 4+----------- + 
| 11001100 | LLLLLLLL | vvvv vvvv 
4+---------- 4+---------- 4+----------- + 


4.13.4 Source Routing 


Like the strict source route option of IP, the Complete Source Route 
option of CLNP is used to specify the exact and entire route an 
internet datagram MUST take. Similarly, the Partial Source Route 
option of CLNP provides the equivalent of the loose source route 
option of IP; i.e., a means for the source of an internet datagram to 
supply (some) routing information to be used by gateways in 
forwarding the internet datagram towards its destination. The 
identifiers encoded in this option are network entity titles, which 
are semantically and syntactically the same as NSAPAs and which can 
be used to unambiguously identify a network entity in an intermediate 
system (router). 


The parameter code for Source Routing is binary 1100 1000. The length 
of the source routing parameter value is variable. 


The first octet of the parameter value is a type code, indicating 
Complete Source Routing (binary 0000 0001) or Partial Source Routing 
(binary 0000 0000). The second octet identifies the offset of the 
next network entity title to be processed in the list, relative to 
the start of the parameter (i.e., a value of 3 is used to identify 
the first address in the list). The offset value is modified by each 
router using a complete source route or by each listed router using a 
partial source route to point to the next NET. 


The third octet begins the list of network entity titles. Only the 
NETs of intermediate systems are included in the list; the source and 
destination addresses shall not be included. The list consists of 
variable length network entity title entries; the first octet of each 
entry gives the length of the network entity title that comprises the 
remainder of the entry. 


4.13.5 Record Route 


Like the IP record route option, the Record route option of CLNP is 
used to trace the route a CLNP datagram takes. A recorded route 
consists of a list of network entity titles (see Source Routing). The 
list is constructed as the CLNP datagram is forwarded along a path 
towards its final destination. Only titles of intermediate systems 
(routers) that processed the datagram are included in the recorded 
route; the network entity title of the originator of the datagram 
SHALL NOT be recorded in the list. 
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The parameter code for Record Route is binary 1100 1011. The length 
of the record route parameter value is variable. 


The first octet of the parameter value is a type code, indicating 
Complete Recording of Route (0000 0001) or Partial Recording of Route 
(0000 0000). When complete recording of route is selected, reassembly 
at intermediate systems MAY be performed only when all fragments of a 
given datagram followed the same route; partial recording of route 
eliminates or "loosens" this constraint. 


The second octet identifies the offset where the next network entity 
title entry (see Source Routing) MAY be recorded (i.e., the end of 
the current list), relative to the start of the parameter. A value 
of 3 is used to identify the initial recording position. The process 
of recording a network entity title entry is as follows. A router 
adds the length of its network entity title entry to the value of 
record route offset and compares this new value to the record route 
list length indicator; if the value does not exceed the length of the 
list, entity title entry is recorded, and the offset value is 
incremented by the value of the length of the network entity title 
entry. Otherwise, the recording of route is terminated, and the 
router MUST not record its network entity title in the option. If 
recording of route has been terminated, this (second) octet has a 
value 255. 


The third octet begins the list of network entity titles. 
4.13.6 Timestamp 


[Note: There is no timestamp option in edition 1 of ISO/IEC 8473, but 
the option has been proposed and submitted to ISO/IEC JTC1/SC6.] 


The parameter code value 1110 1110 is used to identify the Timestamp 
option; the syntax and semantics of Timestamp are identical to that 
defined in IP. 


The Timestamp Option is defined in STD 5, RFC 791. The CLNP parameter 
code 1110 1110 is used rather than the option type code 68 to 
identify the Timestamp option, and the parameter value conveys the 
option length. Octet 1 of the Timestamp parameter value shall be 
encoded as the pointer (octet 3 of IP Timestamp); octet 2 of the 
parameter value shall be encoded as the overflow/format octet (octet 
4 of IP Timestamp); the remaining octets shall be used to encode the 
timestamp list. The size is fixed by the source, and cannot be 
changed to accommodate additional timestamp information. 
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十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 
[11101110| length | pointer|oflw|flg| 
十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 
| network entity title | 
十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 
| timestamp | 
十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 
| | 
5. Error Reporting and Control Message Handling 


CLNP and IP differ in the way in which errors are reported to hosts. 
In IP environments, the Internet Control Message Protocol (ICMP, [7]) 
is used to return (error) messages to hosts that originate packets 
that cannot be processed. ICMP messages are transmitted as user data 
in IP datagrams. Unreachable destinations, incorrectly composed IP 
datagram headers, IP datagram discards due to congestion, and 
lifetime/reassembly time exceeded are reported; the complete internet 
header that caused the error plus (at least) 8 octets of the segment 
contained in that IP datagram are returned to the sender as part of 
the ICMP error message. For certain errors, e.g., incorrectly 
composed IP datagram headers, the specific octet which caused the 
problem is identified. 


In CLNP environments, an unique message type, the Error Report type, 
is used in the network layer protocol header to distinguish Error 
Reports from CLNP datagrams. CLNP Error Reports are generated on 
detection of the same types of errors as with ICMP. Like ICMP error 
messages, the complete CLNP header that caused the error is returned 
to the sender in the data portion of the Error Report. 
Implementations SHOULD return at least 8 octets of the datagram 
contained in the CLNP datagram to the sender of the original CLNP 
datagram. Here too, for certain errors, the specific octet which 
caused the problem is identified. 


A summary of the contents of the CLNP Error Report, as it is proposed 
for use in TUBA environments, is illustrated in Figure 5-1: 
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0 Í 2 3 
Od.2- -30456 89-091 2-3 4 5 67.8 9.0 12 3 aS 6 7 8 9-0 I 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| Data Link Header........ | NLP ID 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
|Header Length | Version | Lifetime (TTL)| 000 | Type-ER | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| TOTAL Length of Error Report | Checksum 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Dest Addr Len | Destination Address... 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Destination Address... 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Destination Address... 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Destination Address... 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Destination Address... 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
PROTO field | Src Addr Len | Source Address... 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Source Address... 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Source Address... 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Source Address... 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Source Address... 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
... Source Address | Reason for Discard (type/len) | 
| 1100 0001 | 0000 0010 | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Reason for Discard | Options... 
code | pointer | | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Options 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Data | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


一 … 一 + 一 一 + 一 一 + 一 + 一 + 一 + 一 + 一 + 一 + 一 + 一 + 一 


Note that each tick mark represents one bit position. 


Figure 5-1. Error Report Format 
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for processing an Error Report 


The following is a summary of the rules for processing an Error 


Report: 


* 


Piscitello 


An Error Report is not generated to report a problem 
encountered while processing an Error Report. 


Error Reports MAY NOT be fragmented (hence, the 
fragmentation part is absent). 


The Reason for Discard Code field is populated with one of 
the values from Table 5-1. 


The Pointer field is populated with number of the first 
octet of the field that caused the Error Report to be 
generated. If it is not possible to identify the offending 
octet, this field MUST be zeroed. 


If the Priority or Type of Service option is present in the 
errored datagram, the Error Report MUST specify the same 
option, using the value specified in the original datagram. 


If the Security option is present in the errored datagram, 
the Error Report MUST specify the same option, using the 
value specified in the original datagram; if the Security 
option is not supported by the intermediate system, no Error 
Report is to be generated (i.e., "silently discard" the 
received datagram). 


If the Complete Source Route option is specified in the 


errored datagram, the Error Report MUST compose a reverse of 
that route, and return the datagram along the same path. 
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Table 5-1 provides a loose comparison of ICMP message types and codes 
to CLNP Error Type Codes (values in Internet decimal): 


CLNP Error Type Codes 


Reason not specified (0) 
Protocol Procedure Error (1) 
Incorrect Checksum (2) 
PDU Discarded--Congestion (3) 
Header Syntax Error (4) 
Need to Fragment could not (5) 
Incomplete PDU received (6) 
Duplicate Option (7) 
Destination Unreachable (128) 
Destination Unknown (129) 
Source Routing Error (144) 
Source Route Syntax Error (145) 
Unknown Address in Src Route(146) 
Path not acceptable (147) 
Lifetime expired (160) 
Reassembly Lifetime Expired (161) 
Unsupported Option (176) 
Unsupported Protocol Version(177) 
Unsupported Security Option (178) 
Unsupported Src Rte Option (179) 
Unsupported Rcrd Rte (180) 
Reassembly interference (192) 


ICMP Message (Type, Code) 


Parameter Problem 
Parameter Problem 
Parameter Problem 
Source Quench 
Parameter problem 
Frag needed, DF set 
Parameter Problem 
Parameter Problem 


Dest Unreachable,Net unknown (3, 
Dest Unreachable,host unknown 


Source Route failed 
Source Route failed 
Source Route failed 
Source Route failed 

TTL exceeded 

Reassembly time exceeded 
Parameter Problem 
Parameter problem 
Parameter problem 
Parameter problem 
Parameter problem 
Reassembly time exceeded 


Nox 


~ 


ON ON o8 


~ 


FE PIEDO: DO DD Et COT UOS GO Gok 
~ ~ 
By OO TR T O-O aR TOT O OO O 


~ 


(3 
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1 
1 
1 
1 
1 
1 
1 
1 


一 一 一 一 一 一 一 一 


Table 5-1. Comparison of CLNP Error Reports to ICMP Error Messages 


Note 1: The current accepted practice for IP is that source quench 


should not be used; if it is used, 


implementations MUST 


not return a source quench packet for every relevant packet. 
TUBA/CLNP implementations are encouraged to adhere to these 


guidelines. 


Note 2: There are no corresponding CLNP Error Report Codes for the 
following ICMP error message types: 

- Protocol Unreachable (3, 

- Port Unreachable (3, 

[Note: Additional error code points available in the ER type 

code block can be used to identify these message types.] 
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2) 
3) 
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6. 


Pseudo-Header Considerations 


A checksum is computed on UDP and TCP segments to verify the 
integrity of the UDP/TCP segment. To further verify that the UDP/TCP 
segment has arrived at its correct destination, a pseudo-header 
consisting of information used in the delivery of the UDP/TCP segment 
is composed and included in the checksum computation. 


To compute the checksum on a UDP or TCP segment prior to 
transmission, implementations MUST compose a pseudo-header to the 
UDP/TCP segment consisting of the following information that will be 
used when composing the CLNP datagram: 


* Destination Address Length Indicator 

* Destination Address (including PROTO field) 
* Source Address Length Indicator 

* Source Address (including Reserved field) 

* A two-octet encoding of the Protocol value 
* TCP/UDP segment length 


If the length of the {source address length field + source address + 
destination address field + destination address } is not an integral 
number of octets, a trailing 0x00 nibble is padded. If GOSIP 
compliant NSAP addresses are used, this never happens (this is known 
as the Farinacci uncertainty principle). The last byte in the 
Destination Address has the value 0x06 for TCP and 0x11 for UDP, and 
the Protocol field is encoded 0x0006 for TCP and 0x0011 for UDP. If 
needed, an octet of zero is added to the end of the UDP/TCP segment 
to pad the datagram to a length that is a multiple of 16 bits. 


[Note: the pseudoheader is encoded in this manner to expedite 
processing, as it allows implementations to grab a contiguous stream 
of octets beginning at the destination address length indicator and 
terminating at the final octet of the source address; the PROTOCOL 
field is present to have a consistent representation across IPv4 and 
CLNP/TUBA implementations.] 
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Figure 6-1 illustrates the resulting pseudo-header when both source 
and destination addresses are maximum length. 
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Destination Address. 
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(PROTO) | Src Addr Len | Source Address. 
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Figure 6-1. Pseudo-header 


7. Security Considerations 


ISO CLNP is an unreliable network datagram protocol, 
security considerations as Internet Protocol 
conveying the same security handling information 


to the same 
methods for 


recommended for IP are described in Section 4.13.1, 
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and is subject 


([51, [8]); 


Security Option. 
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H- 
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(from ISO/IEC 8473) 


eL variables used in the algorithms 
position of octet in header (first 
octet is i-1) 
value of octet i in the header 
position of first octet of checksum (n=8) 


Length of header in octets 


Value of octet one of the checksum parameter 
Value of octet two of the checksum parameter 


Addition is performed in one of the two following modes: 


* modulo 255 arithmetic; 


* eight-bit one’s complement arithmetic; 


The algorithm for Generating the Checksum Parameter Value is as 


follows: 


A. Construct the complete header with the value of the 
checksum parameter field set to zero; 


i365; 


GD < cL <= 0} 


B. Process each octet of the header sequentially from i-1 to L 


by: 


* c0 «- cO + Bi 


* cl <- cl + cO 


C. Calculate X, Y as follows: 


* 


X 


«- (L- 8)(c0 - 
<- (L - 7) (-C0) 
0, then X «- 255 


0, then Y «- 255 


c1) 


+ cl 


modulo 255 


F. place the values of X and Y in octets 8 and 9 of the 
header, respectively 


The algorithm for checking the value of the checksum parameter is as 


follows: 


Piscitello 


[Page 24] 


RFC 1561 CLNP in TUBA Environments December 1993 


A. If octets 8 and 9 of the header both contain zero, then the 
checksum calculation has succeeded; else if either but not 
both of these octets contains the value zero then the 
checksum is incorrect; otherwise, initialize: c0 <- cl <- 0 


B. Process each octet of the header sequentially from i = 1 to 
L by: 


* 60° «--cO- * BI 


* cl «- cl + cO 


C. When all the octets have been processed, if c0 = cl = 0, 
then the checksum calculation has succeeded, else it has 
failed. 


There is a separate algorithm to adjust the checksum parameter value 
when a octet has been modified (such as the TTL). Suppose the value 
in octet k is changed by Z - newvalue - oldvalue. If X and Y denote 
the checksum values held in octets n and n+l1 respectively, then 
adjust X and Y as follows: 


If X= 0 and Y = 0 then do nothing, else if X = 0 or Y = 0 then the 
checksum is incorrect, else: 


X <- (k - n -1)2 + X modulo 255 

Y <- (n - k)Z + Y modulo 255 

If X = 0, then X <- 255; if Y = 0, then Y <- 255. 

In the example, n = 89; if the octet altered is the TTL (octet 4), 
then k = 4. For the case where the lifetime is decreased by one unit 
(Z = -1), the assignment statements for the new values of X and Y in 
the immediately preceeding algorithm simplify to: 


X <- X +5 Modulo 255 


Y <- Y - 4 Modulo 255 
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